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ABSTRACT 

The  MILOS  (Military  Systems  based  on  Open-source  Software)  project  was  a  European  research  program 
in  the  Eurofinder  framework,  attached  to  the  CEPA  6  and  co-financed  by  the  Ministry  of  Defence  of 
France  and  Spain.  The  companies  involved  were  THALES  and  GMV. 

The  MILOS  project  aimed  to  demonstrate  benefits  of  Open  Source  Software  in  large  software  based 
military  systems,  by  casting  off  constraints  inherent  to  traditional  proprietary  COTS  and  by  taking 
advantage  of  new  opportunities,  which  occur  thanks  to  OSS’s  characteristics. 

The  goal  of  MILOS  was  to  analyse  the  feasibility  of  the  use  of  Open  Source  software  in  military  systems. 
This  paper  is  a  brief  introduction  to  Open  Source  and  its  possible  eventual  relationship  with  both 
government  and  military  agencies. 


1.  INTRODUCTION 

2.  WHAT  IS  OPEN  SOURCE  SOFTWARE 

A  simple  definition  of  ‘open  source’  software,  sometimes  referred  to  as  ‘free’  or  ‘fibre  software’,  is  that 
the  software’s  source  code  is  available  to  the  public.  However,  simply  making  the  source  code  available 
does  not  necessarily  mean  that  a  program  meets  the  definition  of  open  source  software.  In  order  to  classify 
a  program  as  open  source  software,  its  license  must  comply  with  some  criteria.  These  criteria,  designed  to 
represent  the  consensus  view  on  just  what  open  source  software  is,  are  the  following: 

•  Source  code 

The  program  must  include  the  source  code,  and  must  allow  distribution  in  source  code  as  well  as  in 
compiled  form.  Where  some  form  of  a  product  is  not  distributed  with  source  code,  there  must  be  a 
well-publicised  means  of  downloading  the  source  code,  without  charge,  via  the  Internet.  Deliberately 
obfuscated  source  code  is  not  allowed.  Intermediate  forms  such  as  the  output  of  a  pre-processor  or 
translator  are  not  allowed. 
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•  Integrity  of  the  author’s  source  code 

It  is  strongly  recommended  that  “none  of  the  authors  restrict  any  files,  source  or  binary,  from  being 
modified”.  The  license  must  explicitly  permit  distribution  of  software  built  from  modified  source 
code.  The  license  may  require  derived  works  to  have  a  different  name  or  version  number  from  the 
original  software. 

•  Derivative  works 

The  license  must  allow  modifications  and  derived  works  and  must  allow  them  to  be  distributed  under 
the  same  terms  of  the  license  of  the  original  software. 

•  ‘Free’  redistribution 

The  license  may  not  restrict  any  party  from  giving  away  (or  selling)  the  software. 


So,  ‘closed  source’  or  ‘proprietary’  software  is  defined  as  software  that  does  not  meet  the  criteria  stated 
above.  For  example,  with  closed/proprietary  software,  a  typical  user  is  neither  allowed  to  access  to  the 
source  code  nor  to  modify  the  source  code,  and  is  usually  prohibited  from  redistributing  the  software. 
Virtually  every  type  of  open  source  software  has  some  variant  of  an  open  source  software  license 
associated  with  it.  In  fact,  the  use  of  open  source  licensing  is  an  essential  element  in  making  open  source 
program  ‘open  source.’ 

One  should  also  note  that,  when  the  word  ‘free’  is  used,  it  does  not  necessarily  mean  the  same  thing  as 
‘zero  price4  ‘free’,  in  relation  to  open  source  software,  means  ‘freedom’  from  constraints. 


3.  SUMMARY  OF  WORKS  AND  OUTPUTS  OF  THE  MILOS  PROJECT 

The  first  stream  of  the  performed  work  was  to  identify  and  to  analyse  stakes  of  OSS  within  software  based 
military  systems.  Then  to  propose  an  organisation  that  enables  to  benefit  from  OSS  while  reducing  its 
related  risks.  Such  analysis  and  proposals,  which  followed,  have  been  carried  on  by  comparison  with  the 
COTS  approach. 

The  second  stream  of  the  work  was  devoted  to  apply  those  findings  to  the  development  of  an  OSS  based 
demonstrator. 

These  two  streams  were  strongly  connected,  the  first  one  providing  guidelines  and  process  to  the  second 
one  which,  in  return  has  provided  fruitful  feedback  to  tune  and  adapt  findings  of  the  theoretical  approach. 

The  first  phase  dealing  with  the  theoretical  study  started  with  the  compilation  of  the  requirements  of  the 
client/supplier  chain,  where  the  OSS  world  was  first  understood,  with  its  actors  and  their  motivations.  An 
explanation  of  how  particularities  and  qualities  of  OSS  components  lead  to  opportunities  for  the  system 
was  given:  right  features,  maintainability,  tailoring,  favourable  licensing  and  pricing,  standard  respects, 
market  share  (de  facto  standard),  quality/reliability,  performance,  security,  total  cost  of  ownership, 
scalability.  Special  attention  was  paid  to  how  some  of  these  characteristics  (mainly  adherence  to  standards 
and  licensing  schema)  should  help  to  the  long-term  maintenance  issue  of  military  systems  (compared  to  a 
COTS  based  solution). 

However,  three  characteristics  of  OSS  were  pointed  out,  which  although  bringing  opportunities,  introduce 
threats  for  the  system:  its  licensing  schema,  to  be  an  “external  component”  and  to  be  in  “continuous 
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evolution”.  A  dedicated  OSS  “evaluation  /  selection  process”  and  emphasis  on  “Configuration 
management”  should  dramatically  mitigate  related  risks  while  enabling  to  fully  benefit  from  OSS.  These 
issues,  solutions  and  related  organisational  changes  are  highlighted  in  the  following  section  of  this  paper. 

As  the  proposed  change  to  the  evaluation/selection  process  was  innovative,  it  was  tested  in  the  context  of 
the  development  of  the  “Milos  demonstrator”.  The  scope  of  the  development  was  first  refined  through  a 
technical  requirements  specification,  where  requirements  related  to  the  development  infrastructure  and  to 
the  targeted  application  domain  (functional  subset  of  a  Command  and  Control  Information  System)  were 
highlighted. 

Based  on  the  list  of  product  segments  as  identified  in  the  technical  requirements  specification,  a  general 
OSS  market  survey  was  provided.  It  was  used  as  input  to  the  evaluation  of  candidates  for  each  segment 
relevant  to  the  demonstrator,  evaluation  results  were  in  a  Requirements  compliance  and  trade-off  report. 

The  selection  and  evaluation  process  dealt  with  both: 

•  Technical  topics,  which  are  different  for  each  family  of  tools.  Every  tool  must  be  compliant  to 
some  technical  criteria. 

•  Industrial  topics,  concerning  support,  sponsors,  documentation...  For  Open  Source,  industrial 
topics  play  an  important  role  in  order  to  limit  risks. 

Information  for  both  parts  is  collected,  beginning  with  the  technical  topics.  Since  the  list  of  tools  in  the 
market  survey  report  were,  more  or  less,  in  compliance  with  the  technical  criteria  (technical  requirements 
specification),  all  of  them  were  “industrially”  investigated. 

In  both  cases,  a  set  of  criteria  were  collected  and  weighted  (regards  the  relative  significance).  Later  those 
were  used  to  qualify  the  tools. 

Selection  of  the  components  to  be  integrated  in  the  demonstrator  followed  results  of  the  evaluation  phase 
with  a  few  of  exceptions,  which  took  care  of  a  set  of  constraints  defined  for  the  demonstrator. 

A  test  scenario  was  released  to  functionally  validate  the  demonstrator  and  therefore  the  suitability  of  OSS 
for  military  systems  development.  It  was  also  validated  through  a  previously  defined  validation  plan. 

To  conclude  this  theoretical  work,  relationships  between  the  different  actors  were  studied:  the  OSS 
community,  the  technology  provider  (OSS  support  provider),  the  systems’  integrator  and  the  customer. 
This  study  was  done  from  the  business  points  of  view  of  the  technology  provider  and  the  integrator  roles. 

The  second  phase  of  the  project,  the  practical  application,  started  with  the  installation  of  the  selected  OSS 
components  with  special  care  to  compatibility  (interoperability).  Then  came  the  “glueing”  of  the  OSS 
components  together  with  specific  developments  according  to  specifications  previously  drafted.  After  unit 
testing  and  final  integration,  the  demonstrator  was  evaluated  through  the  operational  and  the  technical 
scenario  previously  defined. 


4.  THE  EVALUATION  PROCESS 

The  evaluation  is  twofold:  the  technical  evaluation  (in  order  to  assess  technical  capacity)  and  the  industrial 
evaluation  (in  order  to  assess  confidence  in  mid-term). 

But,  prior  to  any  kind  of  evaluation  of  an  OSS  candidate,  its  licensing  schema  is  an  issue  that  should  be 
taken  into  account  through  a  legal  analysis.  According  to  how  the  OSS  component  is  used  in  the  system, 
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some  licensing  schema  may  impose  the  redistribution  of  part  (or  even  the  entire)  system  under  the  same 
license  of  the  OSS  component  (such  license  is  called  “viral”  -  e.g.  the  GNU  GPL).  In  such  a  situation,  the 
system’s  integrator  4s  intellectual  property  rights  related  to  those  “OSS  license-affected”  part  are  altered, 
he  is  not  allowed  to  release  this  part  of  the  system  which  uses  the  OSS  in  a  proprietary  system. 
Consequently,  the  legal  analysis  step  is  going  to  act  as  a  first  level  filter  to  eliminate  those  components 
whose  license  doesn’t  comply  with  the  intellectual  property  right  strategy  of  the  integrator  for  the 
considered  system. 

The  technical  evaluation  process  can  be  depicted  as  follows:  for  each  segment  of  products  under 
consideration,  a  list  of  technical  criteria  (featuring  technical  capacity  and  functionality  expected  for 
candidates  in  the  segment  to  be  fulfilled)  is  defined  with  accurate  metrics  (how  to  measure).  The  criteria 
are  “weighted”  to  feature  their  relative  importance  and  to  take  into  account  the  context  of  the  evaluation 
(or  targeted  systems  -  in  Milos,  weights  were  set-up  with  the  command  and  control  information  system 
context  in  mind).  To  allow  comparison  between  candidates  the  valuation  of  criteria  is  normalised  as  well 
as  weights. 

Even  after  having  checked  the  accuracy  of  a  component  to  the  system4 s  technical  requirements,  the 
decision  to  use  such  “external  component”  is  always  a  critical  one,  since  it  creates  a  dependency  link 
between  the  system  (which  is  responsibility  of  the  integrators)  and  this  component  (which  is  responsibility 
of  its  provider).  The  objective  of  the  “industrial”  evaluation  process  is  to  assess  and  mitigate  risks  related 
to  this  kind  of  “dependency  link”  in  a  mid-term  horizon  (3  to  5  years;  a  longer  period  is  meaningless  in  the 
rapidly  moving  software  world). 

For  the  industrial  evaluation,  a  way  to  gain  or  assess  the  confidence  in  an  OSS  through  an  investigation  of 
the  project  life  was  proposed.  The  points  studied  were:  its  lead  maintainers,  its  developers  and 
communities  of  users,  the  usefulness  and  reactivity  of  supporting  information  media  (mailing  lists, 
forums),  consistency  and  accuracy  of  information  released  by  the  project  (roadmaps,  vision),  the  support 
of  major  software  /  computer  industries. 

As  a  conclusion,  both  the  OSS  evaluation  process  and  its  outputs  were  considered  as  major  results  of 
Milos,  and  it  was  our  intend  to  share  such  information  and  to  establish  co-operation  with  other  industrials, 
which  share  the  same  concerns  (i.e.  which  look  for  integration  of  OSS  in  systems  having  a  long-term 
maintenance  constraint). 

•  When  running  the  evaluation  process,  we  have  investigated  more  than  40  segments  (families  of 
products)  covering  330  OSS.  The  effort  needed  to  run  the  investigation  was  high,  especially  for 
the  industrial-like  investigation  for  which  we  have  simplified  the  criteria.  As  a  future  direction,  it 
could  be  worth  to  automate  part  of  this  investigation  (e.g.  to  look  for  utilities  that  compute  some 
criteria  as:  the  average  number  of  mails  per  day/month,  the  mean  time  between  question  and 
answer,  growth  of  traffic,  growth  of  the  community,  identification  of  main  people  that  answered 
questions). 

•  The  investigation  output  was  a  snapshot  of  the  OSS  market  at  the  time  the  study  was  done,  to 
keep  alive  such  information  we  have  proposed  to  release  it  to  the  public  with  the  aim  at  federating 
users  and  experts  communities  through  a  dedicated  portal.  We’ve  passed  information  to  the  eCots 
portal  (www.ecots.org,  software  components  open  directory  project)  which  provides  products 
segmentation  and  facilities  to  host  a  community. 
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5.  THE  CONFIGURATION  MANAGEMENT 

One  major  point  with  OSS  is  its  frequent  releasing  policy,  which  allows  integrating  rapidly  bugs  fixing 
and  enhancements;  this  is  also  considered  as  a  crucial  feature  to  keep  active  the  developers  and  users 
community. 

On  the  other  hand,  system’s  integrators  need  to  freeze  all  components  that  are  part  of  the  system  for  a 
period  of  time  that  is  compatible  with  development  constraints  (integration  of  external  components  with 
the  developed  applications).  Between  keeping  in  touch  with  the  latest  edge  of  the  project  and  stability,  a 
trade-off  needs  to  be  taken. 

Stability  is  needed  for  either  the  development  phase  of  the  systems  but  also  to  enable  corporate 
capitalisation  of  know-how  related  to  those  components. 


5.1  Stability  and  the  system  context 


Freezing  OSS  components  doesn’t  mean  that  it  is  no  more  possible  to  integrate  some  corrective  patches; 
the  decision  to  do  so  depends  on  the  issues  the  patches  correct  (e.g.  blocking  bugs  or  security  holes).  It 
should  also  be  noted  that  some  corrections  lead  to  a  new  version  of  the  component;  this  is  under  the 
responsibility  of  the  OSS  lead  maintainer,  who  decides  depending  on  the  severity. 

In  addition,  the  integrator  may  have  modified  the  current  version  of  the  OSS  to  adapt  it  to  the  system’s 
specificity;  it  is  highly  recommended  that  such  modifications  are  tracked  through  patch  mechanisms  in 
order  to  stay  compatible  with  what  is  done  by  the  community. 

Where  there  is  no  dedicated  organisational  entity  to  manage  the  OSS  (see  below),  it’s  responsibility  of  the 
system’s  team  to  manage  versions  of  the  component,  its  patches  as  released  by  the  community,  its  patches 
as  released  internally  to  cope  with  contextual  adaptation  and,  all  the  related  documentation.  This  is 
mandatory  to  be  able  to  rebuild  at  any  time  the  actual  version  of  the  component  that  is  in  use  in  the  system 
and  will  make  easier,  further  replacement  of  this  component. 

Such  a  version  management  of  OSS  is  then  integrated  in  the  system  configuration  management  to  provide 
the  full  figure  of  what  has  been  used  and  integrated. 


5.2  Stability  and  the  organisational  context 

According  to  the  frequency  of  usage  of  a  component  within  a  system,  a  dedicated  unit  should  be  defined  in 
the  integrator’s  organisation.  This  unit  will  take  charge  of  supplying,  adapting  (internal  patches),  releasing 
to  businesses  and  deciding  updates  policy  (when  and  which  version  of  the  OSS  component  to  use,  whether 
to  apply  patches  as  released  by  the  community  or  not).  This  entity  will  act  as  interface  between  the 
systems  development  teams  and  the  OSS  communities;  they  may  also  provide  some  kind  of  support  to 
their  internal  customers.  In  such  a  case  this  entity  will  manage  the  actual  versions  of  components  as 
released  to  systems  developers  (i.e.  the  OSS  and  subsequent  patches  that  may  have  been  applied  to  build 
the  “internal  reference”  released  to  systems  developers). 

Systems  development  teams  should  use  this  customised  version  of  the  OSS  as  its  reference  and  may  adapt 
it  to  systems  constraints  if  needed  (contextual  patches). 
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6.  USE  AND  INTEGRATION  OF  OSS  (THE  TECHNICAL  VIEW) 

It  was  not  the  aim  of  the  project  to  build  a  full-fledged  operational  system.  Nevertheless  the  development 
of  the  Milos  demonstrator  allowed  to  point  out  some  issues  and  to  verify  some  advantages  of  OSS. 

A  summary  of  this  phase,  which  emphasises  key  points  related,  could  be  the  following: 

•  The  Framework  installation 

Before  installation  was  broached,  an  installation  manual  for  each  OSS  tool  to  be  use  was  prepared.  It 
greatly  helped  the  framework  installation. 

No  real  difficulty  was  encountered  in  the  operating  system  installation  (made  in  dual-boot  with 
Windows)  but  it  requires  standard  skills  in  Unix  administration.  Concerning  tools,  a  choice  had  to  be 
made  between  RPM  or  source  installation.  The  second  option  was  preferred,  since  it  is  considered 
better  for  the  system  mastering. 

A  set  of  tools  had  a  really  straightforward  installation  process  (17  out  of  28),  some  only  needed 
configuration  (9)  and  only  two  were  really  difficult  to  install.  On  tool  (Subversion)  had  to  be  changed 
since  it  did  not  fulfil  our  needs,  but  this  tool  was  not  a  final  release  (not  mature  enough).  Mailing  lists 
were  of  great  help  during  the  process. 

The  main  conclusion  was  that  installing  the  framework  was  quite  easy  except  for  a  few  tools.  It  was 
even  easier  since  many  tools  were  Java-based.  Windows  users  may  however  have  difficulties  to  find 
operating  system  configuration  tools  since  it  requires  some  skills  in  Unix  administration  and  since  they 
are  less  integrated.  The  counterpart  is  that  flexibility  in  configuration  was  proved  to  be  really  good. 

•  The  components  integration 

Main  difficulties  encountered  concerned  tools  versions  mismatch  management,  since  many  low-level 
tools  are  widely  integrated  in  higher  level  tools,  leading  to  large  sets  of  dependencies.  Moreover,  each 
tool  needs  some  prerequisite  knowledge  to  be  gathered  (integrator  experience). 

A  first  phase  during  which  a  coherent  set  of  tools,  or  even  tools  versions,  is  identified  seemed 
necessary.  All  the  development  tools  selected  proved  to  integrate  well. 

Security  aspects  were  however  not  considered  for  the  demonstrator  and  this  may  lead  to  difficulties  in 
a  scope  where  tools  from  very  different  places  are  gathered.  Anyway,  this  should  be  investigated 
deeper. 

•  Specific  development 

Some  tools  do  not  come  with  sufficient  documentation  (our  opinion).  The  main  source  for  developers 
support  used  was  mailing  lists.  It  has  to  be  noticed  that  many  questions  were  already  answered  for 
other  developers  and  did  not  require  posting  a  request.  Even  beginner’s  questions  are  answered. 

Concerning  development  tools,  Eclipse  was  of  great  help  and  was  robust,  powerful,  portable  and 
extensible  (through  plug-ins).  Its  main  drawback  is  a  huge  need  in  resources  (memory,  CPU). 

We  consider  that  OSS  software  used  did  not  bring  difficulties  in  designing  the  architecture  we  planed. 
Some  purely  technical  difficulties  arose,  in  particular  with  xskfo,  which  is  hard  to  write  and  maintain. 

We  globally  consider  that  the  tools  selected  for  development  provided  good  productivity  and  allowed 
us  to  build  all  the  elements  we  planned. 
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Performance  could  be  improved,  at  the  cost  of  an  in-deep  evaluation  of  where  time  is  consumed, 
which  was  only  partly  done  during  the  demonstrator  test  phase,  for  it  corresponds  to  an  important 
effort. 

•  Impact  on  design 

Related  to  impact  on  the  systems  design  of  the  introducing  of  OSS,  there  is  few  to  say,  which  is 
specific  to  OSS.  The  major  point  to  take  care  of,  is  the  fact  that  it  is  an  “external  component”  which 
therefore  should  be  clearly  isolated  from  the  rest  of  the  system  (e.g.  through  wrapping  techniques)  if 
its  API  is  not  standardised;  this  for  the  sake  of  robustness  and  maintainability. 

•  Main  differences  compared  to  COTS 
The  main  differences  noticed  were: 

•  source  code  availability 

•  the  lack  of  tools  for  system  design  (UML  tools,  GUI  builder) 

•  a  good  versioning  system  (CVS)  but  restricted  to  small  to  medium  teams  (no  connection  to  a 
bug  tracking  system) 

•  the  way  to  obtain  support,  which  is  really  different  from  COTS  but  efficient  for  standard 
development  (maybe  not  for  expert  modifications). 

The  office  tool  (OpenOffice)  was  judged  powerful  and  easy  to  use,  but  it  still  has  the  following 
“drawbacks”  (not  technical): 

•  different  interface  for  Windows  users  which  requires  adaptation  time 

•  some  interoperability  loss  with  usual  office  tools. 

•  Future  directions 

Future  directions  could  concern  performance  and  security  aspects. 

Also,  the  following  services  could  be  considered: 

•  directory  services 

•  adaptable  deployment 

•  system  configuration  and  management 

•  formal  electronic  mail  management 

A  more  ambitious  task  could  consist  in  defining  a  complete  runtime  and  development  platform,  taking 
requirements  of  a  real  system  into  account,  mixing  COTS  and  OSS  based  on  the  requirements  for  each 
service. 


7.  CONCLUSIONS 

Besides  technical  considerations,  the  introduction  of  OSS  is  a  change  that  mainly  affects  the  way 
integrators  use  to  work  with  COTS;  as  such,  it  should  be  managed  within  a  project  by: 

•  taking  care  of  “brake”  factors 

•  analysing  new  opportunities  and  threats  of  the  change 
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ORGANIZATION 


•  bringing  out  limitations  of  previous  way  of  doing  as  well  as  regulations  that  had  been  defined  to 
deal  with  those  limitations 

•  proposing  changes  that  take  care  of  the  two  previous  points  and,  gaining  high  management 
implication 

•  conducting  (leadership,  information  and/or  training  sessions)  and  crystallising  the  change  through 
new  procedures  and  organisations. 
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The  utility  of  Open 
Source  software  in 
military  systems 


Introduction 


Objective 

«  to  analyze  all  the  issues  raised  by  the  use  of  Open 
Source  Software  in  military  systems  ...  with  focus 
on  OSS  running  on  Linux  » 


o  A  study: 

•  Competitive  approach  :  «  COTS  Based  Systems  Vs. 
OSS  Based  Systems  » 

•  Risk  Engineering  approach  :  risk  reduction  + 
opportunity  increase 

o  A  Show  Case  :  demonstrator  in  the  defense  domain 
o  Strong  interaction  between  both  :  loop 


Open  Source  software  definition 


OSSW  isn't  just  access  to  the  source  code... 

o  Free  redistribution:  no  restrictions 
o  Source  code:  accessibility 
o  Derived  works:  modifications  are  allowed 
o  Integrity  of  the  author's  source  code: 

•  no  "modified  distribution"  if  patch  files  are  allowed 

•  explicitly  permit  distribution  of  SW  built  from  modified 
source  code 

•  version  number  of  the  original  SW 

o  No  discrimination  against  persons  or  groups 

o  No  discrimination  against  fields  of  endeavour  (this 
includes  military  purposes) 
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Open  Source  software  definition 


OSSW  isn't  just  access  to  the  source  code... 

o  Distribution  of  license:  rights  attached  to  the  program 
apply  to  all  to  whom  the  program  is  distributed. 

o  License  must  not  be  specific  to  a  product:  no 
dependence  on  the  program  being  part  of  a  certain 
distribution  (part  of  the  whole) 

o  The  license  must  no  restrict  other  software 
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Summary  of  works 
performed 


How  to  investigate  an  OSS  project  life 


Emergence 

•Initial  objective 
•Initiators 

•Origin  of  the  project 
•Positioning 
•  1st  stable  release 


Taking-off 

•Major  events 
•Successive  stable  releases 
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How  to  investigate  an  OSS  project  life 


Maturity 

Understanding, 

•Current  model  of  development 
•Developers  community 
•Positioning 

•Adherence  to  standards 
•Licensing  scheme 
Support 

•Mailing  lists  I 

•FAQ  £ 

•Forums  ^ 

•Commercial  companies  ?  costs  ? 
Acceptance 
•Echo  in  the  press 
•Related  web  sites 
•Industrials  supporting  the  development 
•Number  of  users 
•Institutional  &  industrials  users 
Future 
•  Roadmaps 
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List  of  investigated  segments  of  software 


o  ORBs  o 

o  MOMs  o 

o  Security  o 

o  Application  Servers  o 

o  JVM  o 

o  IDES  o 

o  XML  tools  o 

o  Data  conversion  tools  o 

o  XML  middleware  o 

o  Databases  o 

o  Persistency  tools  o 

o  Loose  integration  tools  o 

o  Management  tools  o 

o  GUI  building  tools  o 

o  GroupWare  o 

o  Mail  servers  o 

o  Compilers  o 


Text  editors 

Bug  tracking  tools 

Desktop 

Source  Browsers 
Database  graphical  design 
GUI  testing  tools 
Software  testing  tools 
Deployment  tools 
Requirements  management 
UML  modular  tools 
Configuration  management 
Performance  measurement 
HMI  and  presentation  tools 
Portable  Communication  tools 
Remote  administration  tools 
Documentation  tools 
Real-time  operating  systems 
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Outputs  of  the  market  survey 


Collected  information 

o  Taking  off 
o  Maturity  of  the  project 

•  Frequency  of  releases 

•  Mailing  lists 

•  Stable/unstable  branches 

•  Number  of  users 

•  Number  of  developers 

•  Industrials  support 

o  Support  for  the  user/developer 
o  General  documentation  of  the  tool 

•  User's  manual 

•  Installation  manual 

•  FAQs 

•  Features 

o  Technical  criteria  regards  each  set  of  tools 
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Outputs  of  the  market  survey 


General  conclusions 

o  Some  branches  are  not  covered  by  the  OS 
community 

o  Some  OS  segments  are  not  at  the  same  level  as 
COTS  counterpart 

o  Sometimes,  conservative  policy 
o  Quick  evolution 
o  Excellent  support 
o  Niches 

o  Also,  a  weighted  punctuation  (both  technical  and 
industrial)  was  obtained  for  each  tool. 
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Demonstrator  overview 


DEMONSTRATOR  GOALS 

o  Illustrate  Open-Source  suitability  for  developing  and 
running  a  military  application 

o  Taking  CCIS  systems  as  a  guiding  example 
o  Scenarios  were  defined  and  fulfilled 

HYPOTHESIS 

o  Tools  selection  for  the  demonstrator  will  be  picked  from 
the  market  survey  and  requirements  compliance 
outputs. 

o  Linux  is  the  target  platform 

•  Solutions  respecting  widely  adopted  standards  should 
were  preferred 

•  The  Java  language  should  were  preferred  when  possible 
o  Linux  is  the  target  platform 
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Demonstrator  overview 


Schema 
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Demonstrator  overview 


Functional  breakdown 


Client 


Tactical  Editor 

Document  editing 

Mailing 

Dynamic  Tracks 
Performance  Display 

Web  Browsing 


Third  Party 


Interoperating  Application 
stub 


Dynamic  Tracks  Simulator 


Server 


Web  data  access 

Application  Server 

Office  Document  Export 

Application  Integration  Support 

XML  Import/Export 

Data  Access/Modification/Query 

Mail  Management 


Data  Storage 
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Demonstrator  overview 


Tactical  editor  layout 
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Demonstrator  overview 


Demonstrator  definition 


Dynamic  Tracks 
Simulator 

Interoperable 
Application  stub 

JVM 

Predefined 
XML 
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Demonstrator  overview 


System  architecture 
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MILOS  Lightweight  Clent 
Staff  Headquarters 


MILOS  Tactical  Editor  Client 
Standard  Operator  Position 


MILOS  Server 
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Demonstrator  results 


COTS  vs  OSS 

o  Source  code  availability 

•  helps  understanding  and  integrating  with  the  tools 

•  reading  OSS  source  code  is  a  good  way  to  improve 
developers  skills  for  it  is  often  well  designed  and 
documented 

o  Design 

•  no  UML  tool  used  for  none  of  them  proved  to  be  good 
enough  in  the  market  survey  and  since  COTS  are 
expensive 

•  no  GUI  builder  used  since  developed  HMIs  are  very 
specific 

o  Versioning 

•  CVS  really  well  adapted  for  small  to  medium 
development  teams,  however  it  lacks  a  connection  to 
a  bug  tracking  system 

•  Versioning  OSS  libraries  is  tricky  as  already  mentioned 
(mismatches,  update  difficulties) 
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Demonstrator  results 

COTS  vs  OSS 


o  Support 
•  no  hotline 


•  mailing-lists  very  efficient  for  day-to-day 
development,  probably  less  for  expert  modifications 
requirements 

o  Office  Tools 

•  Easy  and  Friendly 

•  But  use  a  different  look&feel  and  break  some 
compatibility  for  exchanging  documents  with  users  of 
Windows  Office  Tools. 
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Demonstrator  results 

Specific  development 


o 


Some  tools  lack  documentation  (coming  with  the 
tool  itself) 

•  mailing-lists  proved  to  be  helpful 

>  questions  already  answered  for  other  developers 

>  even  newbie  questions  answered 

The  Eclipse  IDE  helped  a  lot 

•  Robust,  powerful,  portable  and  extensible 

•  However  requires  huge  resources  (memory  and  CPU) 


o  Using  OSS  software 

•  did  not  put  any  particular  obstacle  in  developing  the 
planned  architecture  and  features 

•  same  kinds  of  solution  as  for  COTS  were  used 

•  allowed  good  productivity 
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Conclusions 


Specific  development 

o  MILOS  was  a  success 

•  Added-value  of  outputs 

•  Vision  of  the  future 

o  Thanks  to  strong  correlation  of  issues  addressed 
in  MILOS  and  companies'  strategic  vision 

o  MILOS  :  a  contribution  to  pave  the  way  for  a 

spreading  usage  of,  and  deeper  implication  in,  Open 
Source  Software 
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Main  achievements 


Conclusions 


o  MILOS  was  a  success  Accuracy  of  our  Project 
development  methodology. 

•  Competitive  SWOT  analysis  (OSS  Versus  proprietary 
COTS) 

o  OSS  dedicated  "Evaluation  /  Selection"  process 

•  Run  on  a  wide  scope:  350  OSS  through  45  products' 
segments 

•  Gave  positive  results  (see  Technical  feedback) 
o  Organisational  level 

•  Importance  on  dedicated  structure  (legal  issues, 
capitalisation  ...) 

•  Importance  on  strong  configuration  management 
o  Usage  and  integration  of  many  OSS 

•  Development  environment  &  Target  system 

•  Get  support  from  community 

•  Technical  skill 
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